Software Requirement Specification (SRS) document serves as a means of communication between the client (user) and developer because it defines the "what" and "how" of a software project. It contains the purpose, functionality, design, constraint and behavior of the software in which it details how the software should be implemented. SRS should be written in simple and exact language for the client and developer to easily understand and be able to develop the software correctly.
Based on IEEE (Institute of Electrical and Electronics Engineers), following are the basic contents of Software Requirement Specification:
- Software functions � gather information on what the software is supposed to do.
Example: When a module is loaded it should automatically run to gather all export files that ends with .ET in [directory] then load them into the [Database Name] [Tablename].
- Performance � defines the accuracy, speed, response time, availability, and recovery time of different software functions.
Example: For 1 month data to generate, the software should show the report within 60 seconds.
- External interfaces � identifies how the software interacts with people, software from other projects, special-purpose hardware, and other software.
Example: The software should accept valid numeric inputs from the swipe card of the customer for them to avail the 10% promo discount.
- Design constraints � defines the database integrity, required implementation language restrictions, OS, limits on usage of resources such as memory, and others.
Example: The software should be run on a PC that has Mozilla Firefox Web Browser. (Along with the version of the web browser and other requirements such as: hardware specifications and so on.)
- Quality attributes � explains the considerations and constraints on reliability, dependability, portability, security, maintainability, reusability, etc. of the software.
- Other � database, operations, site adapting, and so on.
Typically, the Software Requirement Specification should be complete in identifying what exactly the software will do and cannot do. It should also be consistent so that it won't result to any conflicts with other descriptions of the document.
Software Requirement Specification and Software Testing
Software Requirement Specification requires a good understanding and analysis of the project throughout the software testing.
"What and How should be done"
At this stage, it determines the "what and how should be done" on the software. It validates if the software meets all the requirements specified in the SRS such as the functionality / features, performance, design, and quality of the software. It also verifies how each requirement should be implemented and the behavior of each function executes to other feature of the software.
"What and Why should be included"
Next criteria is to discover the "what and why should be included" on the software. It is important to know the missing requirements in the SRS and then evaluate if it is needed with the other software functions especially if it is relevant in achieving the project's goal.
"What and Why should not"
On the other hand, the "what and why should not" in the SRS is now also feasible at this point because of the actual output of the project during software testing. Again, there must be a reason for disregarding a certain requirement such as it conflicts with other features, less priority or discovered its irrelevance to the entire software project.
Any changes made should comply with Software Requirement Specification.
Conclusion
As the Software Requirement Specification considers the foundation of the project, addressing the complete requirements and relevant keys of the software will avoid confusion and issues throughout the development and delivery stage of the project. Therefore, Software Requirement Specification and Software Testing are relatively essential to achieve the overall functionality and performance of the project.
